Methods and systems for processing transactions

ABSTRACT

Methods and systems are provided for processing a transaction between a first party and a second party. Information defining terms of the transaction and identifying a presentation instrument are received at a host system. Preference information associated with the presentation instrument is retrieved with the host system. The preference information specifies terms for an allocation of transaction amounts among multiple transaction types. An amount for the transaction is allocated among the transaction types in accordance with terms of the transaction and the terms for the allocation.

CROSS-REFERENCES TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.15/968,095, filed May 1, 2018, entitled “METHODS AND SYSTEMS FORPROCESSING TRANSACTIONS,” which is a divisional of U.S. patentapplication Ser. No. 13/426,046, filed Mar. 21, 2012, entitled “METHODSAND SYSTEMS FOR PROCESSING TRANSACTIONS,” which is a continuation ofU.S. patent application Ser. No. 11/055,028, filed Feb. 9, 2005,entitled “METHODS AND SYSTEMS FOR PROCESSING TRANSACTIONS” which is anonprovisional of U.S. Pat. Appl. No. 60/543,513, entitled “METHODS ANDSYSTEMS FOR PROCESSING TRANSACTIONS,” filed Feb. 10, 2004 by SuZanneRogers et al., the entire disclosures of which are incorporated hereinby reference for all purposes.

BACKGROUND OF THE INVENTION

This application relates generally to transaction processing. Morespecifically, this application relates to methods and systems thatprovide presentation instruments used in transactions with multiplefunctions.

Currently, transaction processing is handled in a manner that is largelyfocused on the needs of financial institutions that may be involved inthe transactions as third parties. For example, in the case of credittransactions, a customer is typically provided with a credit card by afinancial institution, with the card having information on it in theform of a magnetic stripe to identify a credit account maintained by thefinancial institution. The customer is able to engage in transactions bypresenting the card information, either by presenting the physical carditself, such as during a transaction at a “brick & mortar” merchantlocation, or by presenting the card number, such as during a telephoneor internet transaction. The transaction is effected by the merchanttransmitting the credit-card information to an authority, who issues anauthorization or denial depending on whether the transaction amountcomports with terms associated with the credit account. The customerdoes not actually pay for the transaction until he makes a payment inresponse to an invoice provided by the financial institution, usually ona monthly basis.

In another example, transactions may be effected using debitinstruments. Such transactions may superficially appear to be similar tocredit transactions in that a customer is provided with a debit card bya financial institution, which may be presented during transactions sothat the merchant may seek approval from an authority. In this instance,however, the authorization depends on a balance in an associatedfinancial account rather than on a predetermined credit limit, and fundsare automatically transferred in response to the transaction. In stillother examples, transactions may be effected using checks or alternativemethods to access demand-deposit-account (“DDA”) funds, whose processingis typically on the order of days and may involve routing through areserve system and/or the Automated Clearing House (“ACH”) system.

Since this structure is focused on the needs of financial institutions,it is unsurprising that there are a number of disadvantages associatedwith it from the perspective of customers and merchants, who are theprincipal parties in transactions. From a customer's perspective, thesystem is rigid, lacking in flexibility to provide significant choice inprocessing, and requiring that the customer maintain multipleinstruments merely to be afforded the ability to engage in differenttypes of transactions. From the perspective of merchants, there arenumerous transaction costs that must be borne and which vary dependingon the level of risk that the transactions represent for the financialinstitutions, and merchants are also denied significant flexibility ofchoice. For example, ACH transactions may be provided at relatively lowcost, debit transactions at intermediate cost and varying depending onwhether they are accompanied by a customer signature, and credittransactions at relatively high cost. The differences in risk to thefinancial institutions that these cost differences represent aregenerally associated with whether the transactions are guaranteed andthe timing with which funds to support them are received.

There is, accordingly, a general need in the art for methods and systemsthat provide greater choice and flexibility to customers and merchants,while also accommodating concerns of involved financial institutions.

BRIEF SUMMARY OF THE INVENTION

Embodiments of the invention make use of a host system having a capacityto interface with parties, such as with merchant systems and customers,through a variety of alternative mechanisms, and also to interface withfinancial institutions that may be involved in transactions. The hostsystem maintains preferences information correlated with individualpresentation instruments or individual customers to effectcustomer-specified ways of treating transactions. The manner in whichsuch transactions are treated thus provides improved flexibility andchoice to both customers and merchants, among other advantages that willbe evident to those of skill in the art after reading this disclosure.

In some embodiments, a method is provided for processing a transactionbetween a first party and a second party. Information defining terms ofthe transaction and identifying a presentation instrument are receivedat a host system. Preference information associated with thepresentation instrument as retrieved with the host system. Thepreference information specifies terms for an allocation of transactionamounts among a plurality of transaction types. An amount for thetransaction is allocated among the plurality of transaction types inaccordance with terms of the transaction and the terms for theallocation.

In one embodiment, the transaction is one of a plurality of transactionsbetween first parties and second parties. The method further comprisesinitiating settlement of the plurality of transactions with the hostsystem in accordance with respective allocations of respectivetransaction amounts among the plurality of transaction types. In anotherembodiment, the transaction is also one of a plurality of transactionsbetween first parties and second parties, and a fraud analysis of theplurality of transactions is performed with the host system.

There are a variety of different types of terms for the allocation thatare within the scope of the invention. For example, in one embodiment,such terms specify one or more transaction types based on anidentification of the second party. In another embodiment, such termsspecify one or more particular transaction types based on anidentification of a type of product included in the transaction. In afurther embodiment, such terms specify one or more particulartransaction types based on the amount for the transaction. In someinstances, the terms may require denial of the transaction if a definedcharacteristic is included in the terms of the transaction. For example,such denial could be required based on an identity of the second partyor an identification of a type of product included in the transaction.

In some cases, the information received at the host system mayadditionally include first-party-identification information, in whichcase the first party may be authenticated on the basis of thefirst-party-identification information. There are a variety of differenttypes of first-party-identification information that might be used. Forexample, the first-party-identification information could comprisebiometric information of the first party, a signature of the firstparty, an encryption certificate, and the like.

Embodiments of the invention may also be used by a number of differenttypes of parties in different relationships. For instance, in oneembodiment, the first party is a customer and the second party is amerchant, with the transaction comprising a transaction for a sale ofgoods or services by the customer from the merchant. In anotherembodiment, the first party is a patient and the second party is ahealthcare provider, with the transaction comprising a transaction forservices provided by the healthcare provider to the patient.

In some instances, the transaction may require that an identifierassociated with the presentation instrument, such as a personalidentification number, be provided. In such embodiments, the host systemmay receive an identifier purportedly associated with the presentationinstrument and verify that it is associated with the presentationinstrument. The presentation instrument may also comprise a markidentifying it as available for use with the host system in someembodiments.

Embodiments of the invention may also accommodate the use of differenttypes of value. For instance, in one embodiment, the terms of thetransaction require payment to the second party using a first form ofvalue and at least one of the plurality of transaction types identifiesa second form of value distinct from the first form of value. In such anembodiment, the second form of value is converted to the first form ofvalue. Such value conversions may also be made in embodiments where afinancial account is replenished. A request may be received from thefirst party to replenish a financial account associated with the firstparty by the host system, with the request identifying a secondfinancial account to act as a source of replenishment value. A transferof value may then be made from the second financial account to the firstfinancial account in accordance with the request. If the first financialaccount maintains a first form of value and the second financial accountmaintains a second form of value distinct from the first form of value,the second form of value may be converted to the first form of value.

In some embodiments, a request for an authorization for the transactionis also made. The authorization request may be made from a third-partyguarantor. In one embodiment, an optimal routing for an authorizationrequest through a network interfaced with the host system is determined.The request is transmitted through the network over the determinedoptimal routing.

The methods of the invention may be embodied in a computer-readablestorage medium having a computer-readable program for directingoperation of a host computer. The host computer may include acommunications system, a processor, and a storage device. Thecomputer-readable program includes instructions for operating the hostsystem to process transactions in accordance with the embodimentsdescribed above.

BRIEF DESCRIPTION OF THE DRAWINGS

A further understanding of the nature and advantages of the presentinvention may be realized by reference to the remaining portions of thespecification and the drawings wherein like reference numerals are usedthroughout the several drawings to refer to similar components. In someinstances, a sublabel is associated with a reference numeral and followsa hyphen to denote one of multiple similar components. When reference ismade to a reference numeral without specification to an existingsublabel, it is intended to refer to all such multiple similarcomponents.

FIG. 1 is a block-diagram representation of an exemplary architecturefor implementing methods of the invention in an embodiment;

FIG. 2 is a more detailed block-diagram representation of a logicalstructure of a host system that may be used in implementing embodimentsof the invention;

FIG. 3 is a schematic illustration of a physical structure of the hostsystem on which methods of the invention may be embodied;

FIGS. 4A and 4B are flow diagrams illustrating point-of-sale enrollmentmethods used in embodiments of the invention; and

FIGS. 5A-5D are flow diagrams illustrating methods of the invention indifferent embodiments.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of the invention provide methods and systems for processingtransactions between parties. These embodiments make use of a hostsystem configured to perform functions in processing a variety ofdifferent types of transactions, which may in some instances beinitiated for the same customer with a single presentation instrument,although in other embodiments may use multiple presentation instruments.For exemplary purposes, the following discussion frequently identifiesthe two parties to a transaction as a customer and a merchant orfinancial institution, but such references are not intended to belimiting. More generally, the methods and systems described herein maybe used in processing transactions between any parties, includingtransactions between two individuals, between two companies, between acompany and an individual, and the like. In those embodiments where theparties comprise a merchant or financial institution and a customer, thetransaction is generally a commercial transaction, but the invention isalso not limited to commercial transactions and may comprise any type oftransaction between parties. Other examples of transactions may includetransactions where the first party is a patient and the second party isa healthcare provider, with the transaction comprising a transaction forhealthcare services provided by the healthcare provider to the patient.

As used herein, the term “presentation instrument” is intended to referto any document or device that includes information identifying thefirst party to a transaction, usually the payor, and that may be used toinitiate processing of a transaction as described herein. In someembodiments, the first party is customer. For example, a presentationinstrument could comprise a magnetic-stripe card, such as a credit card,debit card, stored-value card, payroll card, private-label card, loyaltycard, and the like. Alternatively, a presentation instrument couldcomprise a card having a barcode or could comprise a chip card,sometimes referred to as a “smart” card that includes an embeddedmicrochip. In some instances, the presentation instrument could comprisea check or other negotiable instrument. Radio-frequency identificationdevices (“RFIDs”) may sometimes be used as presentation instruments, andmay be implemented in a wide variety of forms, such as key fobs, cellphones, automatic toll-pass transponders, and the like. In someembodiments, the presentation instrument may even comprise a biometricof a first party, such as the first party's voiceprint, retinal image,or other biometric. Still other cardless presentation instruments may beused in further embodiments.

Also, references herein to “transaction types” is intended to refer todistinct groups of transactions that have common processingcharacteristics. Examples of transaction types include credittransactions, debit transactions, ACH transactions, stored-valuetransactions, and the like. Credit transactions include thosetransactions in which a financial institution provides funds on behalfof a first party in accordance with a credit agreement; many individualsmay have multiple credit arrangements with different financialinstitutions or even with the same institution. Debit transactionsinclude those transactions in which funds are transferred from afinancial account of the first party automatically in response to thetransaction; many individuals may also have multiple debit arrangementswith the same or different financial institutions in variousembodiments. ACH transactions include those transactions that make useof the Automated Clearing House, including a variety of electronic-checkor other electronic-commerce payments. Stored-value transactions includethose transactions in which a prepaid amount is associated with apresentation instrument; execution of the transaction results in areduction of the prepaid amount in accordance with the amount of thetransaction.

Embodiments of the invention also provide for use of different forms of“value,” which is used generically herein to refer to anything havingfinancial worth. For example, value may include any type of currency,such as U.S. dollars, euro, U.K. pounds, and the like, and may alsoinclude other quantities having financial worth. Other examples includeaccumulated cellular-telephone minutes, loyalty points, airline miles,coupons, and the like. In addition, value may include electroniccurrency of a type to be designed specifically for use in electronictransactions, such as on the Internet, as a form of digitally mintedcoin. This and other forms of financial worth not yet developed areintended to be within the scope of the term “value.” References to a“financial account” are accordingly also intended to be construedbroadly, referring to an account that maintains an identification of anytype of value; as used herein, a “financial account” may holdcellular-telephone minutes, airlines miles, and the like, in addition toholding more traditional forms of value by specifying a level ofcurrency.

FIG. 1 provides a schematic illustration of how the host system 100 maybe integrated within an architecture to support the variety oftransaction types that are enabled by embodiments of the invention. Thehost system 100 is configured for communication with a variety ofdifferent entities, including financial institutions 108 that may beinvolved as third parties to transactions, as well as merchants andcustomers who may be direct second and first parties to thetransactions. Interactions with the host system and second parties maytake place with merchant systems 104 that are configured to performmerchant-end processing functions. Communication between the host system100 and the merchant systems 104 and financial institutions 108 is shownas comprising dedicated communication lines, but it will be appreciatedthat such communication may take place through any suitablecommunications arrangement, including through a variety of types ofnetworked configurations, including wide-area networks, local-areanetworks, wireless networks, and the like.

There are a variety of specific ways in which customers may communicatewith the host system 100 and/or merchant systems 104, some of which areindicated explicitly in FIG. 1. These different communicationsmechanisms may support different types of presentation instruments, someexamples of which are shown explicitly in FIG. 1 for the differentcommunications mechanisms indicated. For example, in some embodiments,communications may take place over the Internet 112 or other publicnetwork system that supports interfaces to computational devices such aspersonal computers, PDAs, and the like. In many instances, an identifierfor the presentation instrument may be communicated by inputtinginformation for the presentation instrument with a keyboard or similardevice. For example, with a transaction involving a credit card, thecredit-card number may be typed in together with a related identifiersuch as the expiration date of the card and/or a security code that maybe printed on the back of the card. In other instances, the presentationinstrument may take the form of a computer-readable storage devicehaving information stored on it that may be extracted to function in afashion similar to a debit card. An example of such a presentationinstrument is described in U.S. patent application Ser. No. 09/394,143,entitled “SYSTEM AND METHOD FOR PROVIDING SECURE SERVICES OVER PUBLICAND PRIVATE NETWORKS USING A REMOVABLE, PORTABLE COMPUTER-READABLESTORAGE MEDIUM AT A NETWORK ACCESS DEVICE,” filed Sep. 10, 1999 by PaulCharles Turgeon, and Ser. No. 10/086,793, entitled “SYSTEM AND METHODFOR PERFORMING SECURE REMOTE REAL-TIME FINANCIAL TRANSACTIONS OVER APUBLIC COMMUNICATIONS INFRASTRUCTURE WITH STRONG AUTHENTICATION,” filedMar. 1, 2002 by Paul Charles Turgeon, the entire disclosures of both ofwhich are incorporated herein by reference for all purposes.

In other embodiments, the communications may take place at a kiosk 116,which may be equipped with a variety of different types of readingdevices to enable extraction of relevant information from acorresponding variety of different presentation instruments. Forexample, a kiosk might be configured with a magnetic-stripe reader toread magnetic-stripe cards, including credit, debit, stored-value, andother such cards. The kiosk might additionally or alternatively beequipped with a chip-card reader to read information from chip cards. Inaddition, the kiosk might additionally or alternatively be equipped witha biometric reader, such as a voiceprint reader, retinal scanner,fingerprint reader, or the like. In some instances, the kiosk mightadditionally or alternatively comprise an radio-frequency reader toenable reading of RFID devices, such as a key fob or other device. Thisis an example of more a more general class of devices that use wirelesscommunication. A magnetic-ink reader might also additionally oralternatively be provided with the kiosk to enable checks or othernegotiable instruments having magnetic-ink characters to be read. Insome instances, the kiosk may include devices for reading informationfrom other documents such as driver's licenses, healthcare cards, andother identification cards. The manner in which such information may beread may depend on the nature of the document, and may include opticalreading, magnetic-stripe reading, chip reading, and the like. Thedrawing also notes that in addition to the specific devices describedabove, the kiosk may also be equipped to perform other types of cardlesstransactions.

In some instances, a point-of-sale device 124 may be provided withsimilar capabilities as those described for the kiosk, enablinginformation to be extracted from a variety of different types ofpresentation instruments, including magnetic-stripe cards, chip cards,customer biometrics, RFID and other wireless devices, checks, driver'slicenses, healthcare cards, and the like, in addition to being equippedto perform a variety of other types of cardless transactions. Thepoint-of sale device 124 may take a variety of different forms,including devices that may be operated by merchant clerks, may beself-operated by customers, or may extract information automatically.Examples of point-of-sale devices that have such varied functionalityare described in the following commonly assigned applications, theentire disclosures of which are incorporated herein by reference for allpurposes: U.S. Prov. Pat. Appl. No. 60/147,889, entitled “INTEGRATEDPOINT OF SALE DEVICE,” filed Aug. 9, 1999 by Randy J. Templeton etal.;U.S. patent application Ser. No. 09/634,901, entitled “POINT OF SALEPAYMENT SYSTEM,” filed Aug. 9, 2000 by Randy J. Templeton et al.; U.S.patent application Ser. No. 10/116,689, entitled “SYSTEMS AND METHODSFOR PERFORMING TRANSACTIONS AT A POINT-OF-SALE,” filed Apr. 3, 2002 byEarney Stoutenburg et al.; U.S. patent application Ser. No. 10/116,733,entitled “SYSTEMS AND METHODS FOR DEPLOYING A POINT-OF-SALE SYSTEM,”filed Apr. 3, 2002 by Earney Stoutenburg et al.;U.S. patent applicationSer. No. 10/116,686, entitled “SYSTEMS AND METHODS FOR UTILIZING APOINT-OF-SALE SYSTEM,” filed Apr. 3, 2002 by Earney Stoutenburg et al.;and U.S. patent application Ser. No. 10/116,735, entitled “SYSTEMS ANDMETHODS FOR CONFIGURING A POINT-OF-SALE SYSTEM,” filed Apr. 3, 2002 byEarney Stoutenburg (sometimes referred to collectively herein as “thepoint-of-sale device applications”). An example of a point-of-saledevice 124 that extracts information automatically is a toll-passreader, which is equipped to recognize radio-frequency signals from apresentation instrument in the form of a toll-pass transponder.

A further mechanism that may be provided to permit communications may bea telephone device 120 that transmits telephone signals over a telephonenetwork to a merchant system 104 and/or the host system. The telephonedevice 120 may be equipped in different ways depending on the type ofpresentation instrument to be used. For example, in the simplest cases,the telephone device may simply convert the voice of the customer sothat identification information may be read by the customer from amagnetic-stripe card, check, driver's license, healthcare card, orsimilar tangible presentation instrument. This voice information couldbe received by a customer-service representative at the merchant orhost, who would then enter the received information to the merchantsystem 104 or host system 100 as necessary. For example, suchinteraction between the customer and service representative could beused as part of a telephone-ordering system to arrange transactions.Alternatively, the voice information could be analyzed byvoice-recognition protocols to extract the relevant informationautomatically. In other instances, such as where the presentationinstrument comprises a customer's biometric, particularly the customer'svoice pattern, the voice information could be analyzed using biometricprotocols to identify the customer. In other cases, the telephone device120 may be equipped to provide dual-tone multiple-frequency (“DTMF”)tones, such as are commonly provided by touch-tone telephones. Thecustomer could then enter information from a tangible presentationinstrument such as a magnetic-stripe card or check manually, with thetelephone device 120 transmitting the DTMF tones to the host system 100or merchant system 104 as required. In addition to these specificdevices, the telephone interface may also be used for the execution ofother types of cardless tranasctions.

Embodiments of the invention may also support traditional mail-orderfunctions 128 in cases where the information identifying thepresentation instrument may be transmitted by mail. For example,information from magnetic-stripe cards might be copied onto order formsby a customer for mailing to a merchant, with the information beingentered manually into the merchant system 104 by a clerk. In anotherembodiment, a check might be mailed with an order made by a customer toa merchant, with the information from the check similarly being enteredmanually into the merchant system 104 by a clerk.

In the various embodiments described in connection with FIG. 1, theremay be a requirement that an identifier, such as apersonal-identification number, be associated with the presentationinstrument. Authorization for a transaction may then require that boththe presentation instrument and the identifier be provided. Forinstance, in an embodiment where the presentation instrument comprisesan RFID embodied in a cellular telephone, authorization for atransaction may require detection of the RFID as well as having acorrect PIN supplied by the person using the cellular telephone. Asimilar requirement may be imposed with any tangible presentationinstrument, including any devices that embody an RFID and any of thevarious types of cards described above, and may in some embodiments byimposed where the presentation instrument comprises a customerbiometric.

In embodiments where the presentation instrument comprises a tangiblepresentation instrument, the presentation instrument or a device thatcomprises the presentation instrument may be marked to indicate that thepresentation instrument is available for use with the system, althoughthis is not required. The mark may allow the system to benefit generallyfrom goodwill generated by an organization supporting the system,allowing the system to gain increased acceptance from a reputation ofconvenience and security. The mark may thus appear on a wide variety ofdifferent types of instruments and devices—on credit cards, debit cards,driver's licenses, healthcare cards, cellular telephones, personalcomputers, software run by personal computers, PDAs, checks, key fobs,multichannel point-of-sale devices, and more. It may also be used onvarious supporting and descriptive material.

The host system 100 may include a variety of different logical modulesthat are used to implement methods of the invention. FIG. 2 provides aschematic illustration of a logical structure that may be implemented bythe host system 100 in an exemplary embodiment. In some instances, themodules will perform administrative tasks, such as maintaining profilesfor customers with preference information as described below, providingreporting functionality, implementing fraud-detection algorithms, andthe like. This set of modules is generally denoted by block 208. Inother instances, the modules are actively used as part of executing atransaction between the customer and merchant, together with theinvolvement of a financial institution. In particular, as part ofexecuting such a transaction, information identifying the presentationinstrument that is used and identifying certain terms of the transactionwill be communicated to the host system 100. This set of modules isgenerally denoted by block 204.

In many embodiments, initial registration of a customer may proceedautomatically when a customer obtains a presentation instrument from afinancial institution 108 or merchant. For example, when a customerobtains a debit card from a bank, the customer may choose to be enrolledwith the host system 100, with the bank forwarding relevant enrollmentinformation to the host system 100 on the customer's behalf. In the casewhere a customer obtains a private-label credit card for a particularmerchant from that merchant, the enrollment information could becommunicated to the host system 100 by the merchant. In other instances,however, the customer may choose to enroll directly with the host system100. Accordingly, a registration module 212 is provided so that it maybe accessed directly by customers using one of the interfaces discussedin connection with FIG. 1. Conveniently, the interface could comprisethe Internet. In other embodiments, enrollment may take place at apoint-of-sale location, such as described in detail in connection withFIGS. 4A and 4B below. Such embodiments advantageously reduce the timetaken for point-of-sale registration mechanisms.

The registration module may also be used by the customer to reviewand/or update information as necessary. Such a feature is particularlyadvantageous in connection with maintaining preferences information,which may be used by the customer to define rules for implementingtransactions according to specified criteria. The preferencesinformation is maintained by a preferences module 216, which may rely onvarious submodules to implement different types of preferences. From theperspective of the customer, the ability for the host system 100 toaccommodate preferences in this way allows the customer considerablygreater flexibility in controlling the financial character oftransactions, even to the extent of treating portions of a singletransaction differently.

A number of different submodules are indicated to illustrate thedifferent types of preferences that may be provided. This list ofexamples is not intended to be exhaustive and various other types ofpreferences that may be implemented will be evident to those of skill inthe art after reading this disclosure. One submodule may provide aconsumer payment profile 224 that indicates the types of payments thatare to be made for different transactions. For example, a consumerpayment profile 224 for one customer might indicate payment levels fortreating different transactions differently. For example, it mightindicate that all purchases less than $100 are to be made by debiting aparticular checking account, that all purchases between $100 and $5000are to be made with Credit Card A, and that all purchases for more than$5000 are to be made with Credit Card B. In another example, thepayments might be split among different transaction types so that thefirst $250 of any transaction is treated as a debit transaction, whileany amount above that is treated as a credit transaction with CreditCard A. In some cases, multiple profiles may even be associated with asingle presentation instrument, usually each of them corresponding to adifferent one of several individuals that may use the presentationinstrument. For example, among a married couple, different profilesmight be maintained for the husband and wife to reflect differentcharacteristics in the way their transactions are to be handled. Instill a further example, a consumer payment profile may specify that ifa stored-value card is provided as the presentation instrument, then theentire transaction is to be executed using value stored on thestored-value card.

The preference information might also include payment preferences basedon an identity of the merchant, as indicated with submodule 228. Forexample, the preferences information might specify that all purchasesmade at Merchant X are to be treated by charging Credit Card A, whileall other purchases are to be made with Credit Card B. In otherinstances, the preference information indicates that certain types ofproducts are to be paid for in different ways, as indicated withsubmodule 232. Merely by way of example, a consumer payment profile 224for one customer might indicate that gasoline purchases are to be paidwith Credit Card A, that food purchases are to be paid by directlydebiting a checking account, and that all other purchases are to be paidwith Credit Card B. In some instances, this preference assignment mayreflect incentives provided by financial institutions that manage thecorresponding accounts to use those accounts for particular purposes.

Submodule 236 provides for the ability to block purchases from beingmade from certain merchants with any of the transaction types. Such afeature may be useful in connection with parental controls where aparent makes certain financial accounts available to a child, but wantsto limit potential abuse of that availability. In cases where the childis the only user of a particular presentation instrument, for example,the preferences could specify that all purchases from Merchants X, Y,and Z are blocked. In cases where multiple profiles are associated witha single presentation instrument, the profiles for the parent and childcould differ, with the parent being permitted to make purchases at anymerchant, but the child being prohibited from making purchases atMerchants X, Y, or Z.

A submodule 240 may also be provided for implementing loyalty programsso that a customer is automatically provided with credit for purchasesin accordance with what transaction types are used according to theprofiles. In particular, it will be appreciated that embodiments of theinvention permit the customer to avoid the need to manage a variety ofdifferent presentment instruments. Instead, the customer could simplyalways use, say, his key fob or loyalty card to perform any variety ofcredit, debit, ACH, or other types of transactions. Integration ofloyalty programs with the host system 100 thus permits the customerstill to obtain the benefits provided by those programs notwithstandingthe particular presentation instrument that is used. This consequentlyenhances and enables the implementation of certain loyalty programs.

Merely by way of example, suppose that a customer presented his debitcard at Merchant W, and has a profile that specifies that alltransactions with Merchant W are to be treated as credit transactionswith a credit account at Financial Institution Q. The customer has setup this profile specifically to retain the loyalty benefits ofperforming those credit transactions when shopping at Merchant W.Accordingly, the host system 100 may effect a credit transaction,notwithstanding the presentation of the debit card, and use the loyaltymodule to ensure that loyalty credit is applied in accordance with theactual way in which the transaction is executed. Examples of structuresthat may be used in implementing loyalty programs are described furtherin copending, commonly assigned U.S. patent application Ser. No.10/079,927, entitled “SYSTEMS AND METHODS FOR OPERATING LOYALTYPROGRAMS,” filed Feb. 19, 2002 by Colleen George and John Cawthorne, theentire disclosure of which is incorporated herein by reference.

When transaction information is transmitted to the host system 100, itwill usually originate with the merchant, as indicated in FIG. 2 withthe interface with an authentication module 220, although they maysometimes originate at different parties or locations. Theauthentication module 220 is configured to use the information that isreceived to verify the identity of the customer. In some cases, suchauthentication may make use of the presentation-instrument informationitself, such as where biometric information is provided, or may make useof supplementary information that is provided with the transactioninformation. For example, a copy of a signature might be transmittedwith the transaction information, in which case the authenticationmodule 220 performs a comparison of the received signature with a filecopy of the signature to verify identity. In other instances, anencryption certificate may be provided, such as in the form of apublic-key infrastructure (“PKI”) certificate, block of informationencrypted with a triple data-encryption-standard (“3DES”) technique orother suitable encryption technique. Still other forms of identificationinformation that may be bundled with the transaction information areknown to those of skill in the art and may be used in alternativeembodiments.

The specific administrative modules designated with label 208 in FIG. 2are provided merely to illustrate the types of administrative functionsthat the host system 100 may perform and are not intended to belimiting. As the figure illustrates, these administrative modules may beaccessed by customers and/or merchants, perhaps depending on thespecific nature of the functions they perform. Thus, merely by way ofexample, a marketing module 244 may be provided to coordinate marketingactivities to customers, merchants, and/or financial institutions. Suchmarketing activities may take the form of sending promotional materialsor offers to the customers and/or merchants, and may make use ofinformation obtained regarding those parties from the transactions thatare processed. In this way, the marketing information may be deliveredin a targeted fashion. A portfolio-management module 248 may be providedto coordinate management of the pool of information that is obtained bythe host system 100, and a related portfolio-analysis module 256 may beprovided to assist in analyzing that information in specific ways. Acustomer-correspondence module 260 and customer-care module 272 may beincluded to coordinate providing information to customers, responding toqueries from customers, and the like. Enrollment into the system may bemanaged by an enrollment module 258 that is supported with a back-officemodule 276 and an enrollment-services module 280 used individually or incombination to coordinate such support functions as maintainingenrollment data, updating enrollment data, and the like. Interactionwith the enrollment module 258 may be used in supporting point-of-saleenrollment processes like those described below in connection with FIGS.4A and 4B.

A fraud/risk detection and management module 252 may be usedadvantageously to detect patterns of behavior that are known to indicatean increased likelihood of fraud. This module may implementsophisticated algorithms that are capable not only of identifyingisolated incidents of fraud involving a single stolen presentationinstrument, but that are also capable of identifying patterns acrossmany presentation instruments and types of transactions. The fraud/riskdetection and management module 252 may thus be used in authenticationof the transactor(s) and transaction(s).

The host system may additionally comprise fulfillment and settlementmodules 264 and 268, which are particularly advantageous in coordinatingthe various financial-transfer operations that will be effected inresponse to the types of transactions that are implemented. Thesemodules provide rules for determining amounts that are due to or fromeach of the financial institutions and merchants to reconcile theimplemented transactions. In addition, since funds for the merchants areusually maintained themselves in financial accounts held at thefinancial institutions, these modules identify which financial accountsare due to be debited by amounts and due to be credited by amounts, andcoordinates instructions to effect such operations as required.

The system may also generally support transactions that involvedifferent types of value, such as the various value types describedabove. In some cases, the different value types may be used directly.One example is where loyalty points are earned by a customer with aparticular merchant who has specific rewards that may be offered whencertain levels are reached. For instance, a chain of department storesmay allow customers to accumulate points as items are purchased,promising the customers the ability to exchange 500 points for a one ofseveral identified items (a toaster, a magazine rack, an electric razor,etc.), the ability to exchange 1000 points for of several (morevaluable) identified items (a cordless drill, a table lamp, a clockfixture, etc), with several such tiers of exchange levels. When thecustomer selects one of such items, the system may permit the loyaltypoints to be exchanged in a direct fashion for the item.

In other instances, the system may apply a conversion among value typesto permit one type of value to be used in supporting a transactionordinarily conducted using a different value type. One example is wherethe department store described above allows customers to make purchaseswith the presentation instruments not only with one conventionalcurrency, say U.S. dollars, but with different currencies, such as withCanadian dollars or with Euro, or even with noncurrency forms of valuelike cellular-telephone minutes or airline miles. The host systemimplements such capability by accepting the payment forms identified asacceptable by the department-store chain.

In a more complex example, the conversion among values is effectivelyhidden from the recipient, with the acceptance of different forms ofvalue and conversion among them being handled by the host system. In anexample of such an embodiment, the department store discussed abovesells merchandise, accepting only U.S. dollars for payment. A customerusing a presentation instrument may still purchase goods from themerchant using different forms of value, relying on the host system toeffect conversions among the different value forms. For instance, thecustomer may specify that she wishes to apply frequent-flyer miles tomake a purchase, with the host system accepting the frequent-flyer milesand providing U.S. currency to support the transaction in the fromdesired by the department store. In this way, the ability to offerincreased choice to customers is enhanced—the customer is not limited byany specific arrangement desired by a particular merchant, but mayinstead make use of abilities of the host system to accommodate otherarrangements. Also, the merchant is similarly advantaged since it is notcompelled to support multiple types of transaction arrangements atincreased complexity and expense to accommodate different customers;instead, it may rely on the capabilities of the host system to act as aninterface between its desired method and those that may be preferred byvarious customers.

While FIG. 2 provides a schematic illustration of a logical structurefor the host system 100, FIG. 3 instead provides a schematicillustration of a physical structure that may be used to implement thehost system 100 in one embodiment. FIG. 3 broadly illustrates howindividual system elements may be implemented in a separated or moreintegrated manner. The host system 100 is shown comprised of hardwareelements that are electrically coupled via bus 326, including aprocessor 302, an input device 304, an output device 306, a storagedevice 308, a computer-readable storage media reader 310 a, acommunications system 314, a processing acceleration unit 316 such as aDSP or special-purpose processor, and a memory 318. Thecomputer-readable storage media reader 310 a is further connected to acomputer-readable storage medium 310 b, the combination comprehensivelyrepresenting remote, local, fixed, and/or removable storage devices plusstorage media for temporarily and/or more permanently containingcomputer-readable information. The communications system 314 maycomprise a wired, wireless, modem, and/or other type of interfacingconnection and permits data to be exchanged with the merchant devices104 or any of the various consumer interfaces illustrated in FIG. 1 toimplement embodiments as described below.

The host system 100 also comprises software elements, shown as beingcurrently located within working memory 320, including an operatingsystem 324 and other code 322, such as a program designed to implementmethods of the invention. It will be apparent to those skilled in theart that substantial variations may be made in accordance with specificrequirements. For example, customized hardware might also be used and/orparticular elements might be implemented in hardware, software(including portable software, such as applets), or both. Further,connection to other computing devices such as network input/outputdevices may be employed.

As previously noted, there may be a variety of different mechanisms thatare used to provide enrollment with the system. In some embodiments,such enrollment is provided as an adjunct to the providing a customerwith a presentation instrument in the first instance, with an Internetinterface permitting the customer to modify the individual parametersgoverning the implementation of his enrollment. In other instances,enrollment may conveniently take place at a point of sale,advantageously increasing the pool of customers that may be targeted. Anoverview of some such methods is provided with FIGS. 4A and 4B. Use ofenrollment methods and systems described herein may permit enrollment tobe achieved significantly more quickly than various prior-art enrollmentmethods. For instance, enrollment that allows a customer to draw onfunds in a demand deposit account like a checking or savings account insupporting transactions may be accomplished in minutes. This means thata customer who wishes to enroll at, say, a point of sale may make use ofthe methods and systems for processing transactions executed during thatvisit to the point of sale. While the discussion below often refers toenrollment at a point of sale for illustrative purposes, such referencesare not intended to be limiting. More generally, enrollment may takeplace at a variety of different locations, including at offices offinancial institutions, with the Internet or over other networks, at acustomer service desk, at in-store aisle locations, at enrollment kioskbooths, and the like. References to a “point-of-sale device” may thusinclude devices like those described in the point-of-sale deviceapplications, but might alternatively comprise personal computers,personal digital assistants, handlheld devices, and the like.

Beginning at block 402 of FIG. 4A, a customer who wishes to enroll withthe system at a point of sale may visit an enrollment representative,who is described below as located at a point of sale, but may be locatedelsewhere in different embodiments as noted above. The followingdiscussion generally describes the enrollment process with theparticipation of an enrollment representative who may explain theoperation and advantages of the system to the customer and help incoordinating the collection of information used for enrollment. In otherembodiments, the role of the enrollment representative may be automatedand provided as part of the functionality of a self-enrollment station.The representative has access to a point-of-sale device like thosedescribed above that permit information to be collected from a varietyof different types of instruments; for instance, the point-of-saledevice may be a device as described in the copending point-of-saledevice applications. In embodiments that use a self-enrollment station,such a point-of-sale device may be provided as part of the station orits various functionalities integrated with those of the self-enrollmentstation.

At block 404, the customer presents an identification instrument.Usually the identification instrument has sufficient information thatthe enrollment representative may compare physical features of theperson presenting it with those identified on the identificationinstrument. For example, a photograph or a description of eye color,hair color, height, and other physical features may be included. Typicalidentification instruments may include driver's licenses, stateidentification cards, passports, resident alien cards (“green cards”),and the like. The ability to match physical features acts as apreliminary check that the person seeking enrollment within the systemis the same person who is authorized to control the underlying financialaccounts that will be used in supporting transactions. In embodimentsthat use a self-enrollment station, mechanisms for using biometricmeasurements and other automatic techniques for checking identity asknown in the art may be used. Identification information is read fromthe identification instrument with the point-of-sale device at block406. This may be done by reading a magnetic-stripe card as is commonlyincluded on driver's licenses or state identification cards, readingoptically encoded data as is done on some resident alien cards, byperforming optical character recognition on cards that lack othermagnetically or optically encoded data, and the like. In some instances,the information may be keyed into the point-of-sale device by theenrollment representative if alternative mechanisms for extracting theidentification information are unavailable. The identificationinformation that is extracted at this step is such information as thename and address of the customer, rather than the physical informationthat was used for an initial identification. In some instances,techniques such as prefilling of known data and seeking confirmation ofdata via commercially available data sources may be used to supplementthe identification extraction.

At block 408, the customer may enter additional personal informationinto the point-of-sale device that is not included on the identificationinstrument. Such information may include information to be used inadministering the system for the customer, such as her telephone number,or may include information to be used in confirming identity for laterprocesses, such as birthdate or other information. At block 410, thecustomer chooses and enters a personal identifier, such as a PIN, intothe point-of-sale device. This personal identifier is generally used toconfirm identity as described below for specific transaction processing.

Once such preliminary information has been provided to the point-of-saledevice, the customer will usually present an identification of afinancial account that is to be used in supporting transactions. Forinstance, in the case of a checking account that is to be used, theaccount identification will usually be a voided check. This is apreferred form of account identification since it may be required thatthe voided check have a magnetically printed account number and beprinted with the name of the customer. Verifying that the name printedon the check matches the name on the identification instrument furtherreduces the risk of fraud. In other instances, though, a deposit slipfor the checking account may be accepted. In other instances, thecustomer may simply provide the account and routing numbers for thechecking account, although such embodiments may be subject to higherrisks of fraud. In embodiments where the financial account is a savingsaccount, a deposit or withdrawal slip may be provided. In embodimentswhere the financial account is a credit account, a credit card may beprovided. In embodiments where the financial account stores other formsof value, such as cellular-telephone minutes or airline miles, astatement from the institution identifying the account number wherethose forms of value are stored may be provided.

A check is accordingly made at block 412 whether the customer haspresented account identification. In the usual course of action whereshe has, account information is read from the account identification oris otherwise provided to the point-of-sale device, such as by having theenrollment representative key the information, at block 414. In otherinstances where no account identification has been provided, thepoint-of-sale device may initiate at block 416 a search of pasttransaction records executed by that customer to see whether anidentification of the account may be recovered in that way. Forinstance, the customer may have used a traditional debit card to accessa checking account in executing a transaction without being part of themore integrated and flexible system described herein. The informationfrom that past transaction may be used at block 416 to identify theaccount information that would otherwise be read from the accountidentification at block 414.

At this point, the customer may be given the option of enrolling anexisting presentation instrument with the system or of having a newpresentation instrument provided. The new presentation instrument mighttake the form of a loyalty card, for instance, that identifies thecustomer with a particular merchant, but whose registration with thesystem may later permit it to be used for other types of transactionsand at other accepting locations as described herein. A check isaccordingly made at lock 418 whether the customer presents an existingpresentation instrument. If so, information is read from thepresentation instrument by the point-of-sale device at block 420. Ifnot, the enrollment representative (or automated system) selects apotential presentation instrument at block 426 and information is readby the point-of-sale device from that selected instrument at block 428.

The point-of-sale device now has sufficient information to transmit anenrollment request to the host system at block 422. Such an enrollmentrequest may include the identification information, such as name andaddress of the customer; the financial account information identifyingthe financial account to be enrolled with the system; and thepresentation-instrument information identifying the presentationinstrument to be enrolled with the system. The host system determineswhether to approve the enrollment request at block 430. Such adetermination may include verifying the existence of and a certaincurrent minimum balance in the identified financial account, checkingthe credit score of the person being enrolled, checking for any adverseindications recorded regarding that person or that account, and thelike.

If approval is granted, the host system establishes a customer accountwith the system, and links that customer account with both thepresentation instrument and the identified financial account at block436. The “customer account” refers to an account used by the host systemto administer the functionality of the system for a particular customerand is in this respect distinct from the various financial accounts thatmay ultimately be used in supporting transactions executed by thecustomer. The customer account typically includes identificationinformation for the customer as well as a specification of everypresentation instrument and financial account supported by the hostsystem for that customer. At block 438, the host system returns anapproval code to the point-of-sale device that originated the request,allowing the point-of-sale device to display an approval message atblock 440. Because of this arrangement, the time between sending theenrollment request and receiving the approval response may be on theorder of minutes, rather than on the order of days or weeks, as mighthave been necessary for certain prior-art arrangements, particularly inthe case of financial accounts that comprise demand deposit accounts. Ifthe presentation instrument was one selected by the enrollmentrepresentative at block 426, then that selected presentation instrumentis delivered to the customer at block 442. Because the approval time wasonly on the order of minutes, the customer may now execute transactionsusing the presentation instrument substantially contemporaneously withenrollment, i.e. during the same visit to the point of sale.

If the host system instead determines that the enrollment request is tobe denied, it returns a denial code at block 432 so that thepoint-of-sale device may display a denial message at block 434.

FIG. 4B uses a flow diagram to illustrate a method by which an enrolledcustomer may add presentation instruments to his customer accountmaintained by the host system. This method may be implemented at anytime after enrollment, whether it be during the same point-of-sale visitwhere enrollment was initiated or performed years later when thecustomer acquires a new presentation instrument. At block 450, thecustomer visits an enrollment representative at a point of sale andthereafter provides information sufficient to identify the customeraccount to be modified. This may include providing an existingpresentation instrument enrolled with the customer account at block 452so that it may be read with the point-of-sale device. At block 454, thecustomer may be required to provide an identification of herself byentering the identification information registered with the system atblock 454. In addition, the customer may be required to provide herpersonal identifier in the form of a PIN at block 456, as a mechanismfor reducing the risk of fraudulent access to the customer account.

Once it has collected this identification information, the point-of-saledevice transmits the data to the host system at block 458 to enable thehost system to verify the data and thereby access the customer accountat block 460. To permit the process to proceed, the host system may thentransmit a verification back to the point-of-sale system at block 462.The presentation instrument that the customer wishes to have identifiedby the system is provided by the customer at block 464, permittinginformation from the additional payment instrument to be read from it atblock 466. This information in transmitted back to the host system fromthe point-of-sale device at block 468, allowing the host system toassociate this additional payment instrument with the customer accountat block 470. Again, this process may take only on the order of minutesto complete, and the customer may thereafter use the additionalpresentation instrument to support transactions from any financialaccounts identified with his customer account.

Methods that may be implemented by the host system in processingfinancial transactions are illustrated with flow diagrams in FIGS.5A-5D. FIG. 5A illustrates an exemplary method by which a customer mayinterface with the host system 100 to enroll a new presentationinstrument for subsequent recognition by the host system 100. Aspreviously mentioned, it is usually the case that the customer willinitially be enrolled automatically when a presentation instrument isacquired from a merchant or financial institution. Accordingly, theenrollment illustrated with FIG. 5A will usually be to add apresentation instrument for an existing customer, but in some instancesthis process may be used to add information about a completely newcustomer as well.

At block 502, the customer contacts the host system 100, such as byusing one of the interfaces described in connection with FIG. 1. Thecustomer provides identification information at block 506, such as inthe form of information from a presentation instrument that is alreadyregistered with the host system 100 or in the form of authenticationdata that may be used when transactions are implemented. Thisidentification information is used to retrieve the customer's profile atblock 508 so that additional preferences information may be added.

The host system 100 thus has a profile for the customer available atblock 510 when the customer is asked to provide an identification of thepayment instrument to be added to the profile. This identification mayvary depending on the type of payment instrument and may correspond, forexample, to financial-account-number and expiry-date information for amagnetic card, to a radio-frequency signature for an RFID device, to arouting number and financial-account number for a check, to a biometricsignature for the individual, or any other information suitable foridentifying the different types of payment instruments discussed above.This identification thus acts as a personal identification indicatorthat may be created with key data from the consumer and later used incombination with the personal identifier for providing access. At block512, the payment instrument is added by the host system 100 to thecustomer's profile with the appropriate identification information. Thecustomer may now specify preferences at block 514 that specify howtransactions initiated with that payment instrument are to be handled bythe host system 100. Such specification may include modifying existingpreferences and may include adding additional financial accounts thatcould be used by the customer's profile in allocating amounts for thetransaction. The enrollment of the additional payment instrument iscompleted at block 516 by adding the updated preference information tothe customer's profile.

The flow diagram of FIG. 5B illustrates an exemplary method by which thecustomer may manage his or her profile information as it maintained bythe host system 100. At block 520, the customer contacts the host system100, again such as by using one of the interfaces described inconnection with FIG. 1. At block 522, the customer providesidentification information so that the host system may authenticate thecustomer at block 524. The identification information could compriseinformation from a presentation instrument that is registered to thecustomer by the host system 100 or could comprise authentication datasuch as is usually provided during transactions. Once the customer hasbeen authenticated, the customer initiates profile-management functionsby requesting preferences information at block 526. The customer profileis retrieved by the host system at block 528 and the preferencesinformation is provided to the customer at block 530. Such retrievalpermits the customer to update the preferences information as desired atblock 532 so that the updated information may be stored in thatcustomer's profile at block 534. In this way, each customer is providedwith the ability to modify profiles to maintain the desired allocationsof transaction amounts among transaction types when transactions areexecuted.

An illustration of how the structure of the host system 100 may be usedin processing a transaction between a customer and a merchant isillustrated with the flow diagram shown in FIG. 5C. The method may beginwith the customer arranging the transaction with the merchant at block536 by any suitable mechanism. For example, in a brick & mortarapplication, the customer may select a number of items for purchase andbring them to a clerk for payment; in a telephone-order application, thecustomer may select items from a catalog and telephone a merchantrepresentative to place an order for the items; in an Internetapplication, the customer may select items presented on a merchant website, and fill an electronic “shopping basket” with the selected items;and the like. At block 538, the customer provides information regardinga payment instrument to the merchant, such as by scanning an RFID keyfob at a brick & mortar location, keying in a credit-card number on anInternet site, providing a voice print as part of a telephone order, andthe like. In response, the merchant system 104 prepares a packet ofinformation for transmittal to the host system 100 at block 540. Thepacket generally contains at least some transaction information and anidentification of the payment instrument. The specific transactioninformation that is included may be very limited, such as in embodimentswhere only the total amount to be paid is included, or may be moreextensive. For instance, the transaction information could identify themerchant, could identify the merchant location, could includeauthentication information also provided by the customer, could providean itemized identification of every item being purchased, and the like.This type of information may be useful in those embodiments where thecustomer preferences information is dependent on such information. Theitemized identification of items being purchased may be derived, forexample, by using Universal Product Code or equivalent informationextracted by reading a bar code affixed to the items or to a labelattached to the items.

After the packet of information is transmitted to the host system 100 atblock 542, a number of functions may be performed by the host system 100with the received information. At block 544, for example, the customermay be authenticated by the host system using any of the techniquesdescribed above in connection with the authentication module 220,including use of biometrics, signatures, encryption certificates,specification of the personal identifier, and the like. If the hostsystem 100 fails to authenticate the customer, the transaction may bedeclined by the host system 100 at block 558, with a decline code beingcommunicated back to the merchant system 104. If the customer isauthenticated, a check may be performed by the host system 100 at block546 to verify that the transaction complies with certain global terms.For example, such a check may be used to ensure that a credittransaction will be within predetermined credit limits, that a debittransaction will be for less than an available balance in a financialaccount, that a stored-value-card transaction will be for less than anamount remaining on the card, and the like. If such global terms are notmet by the transaction, it may be declined at block 558, with a declinecode again being communicated back to the merchant system 104.

If the transaction is to be processed by the host system 100, the hostsystem retrieves customer preferences information at block 548 andapplied the transaction in accordance with those preferences, severalexamples of which were illustrated above. The host system 100 returns anauthorization code back to the merchant system 104 at block 554 toindicate that the transaction has been accepted and executed; thisauthorization code signifies to the merchant that the transaction shouldbe completed between the customer and merchant as indicated.

It will be appreciated that the illustration of FIG. 1 has beensimplified for purposes of illustration. In an actually deployed system,the number of components that may be involved is significantly largerand there may be an even greater number of interconnections among thecomponents. The result is a web-like system that has a large number ofpotential routing paths for information from any two points within thesystem. Moreover, the scale of such interconnection is further enhancedby supporting the diversity of presentation instruments. The host systemmay accordingly be capable of identifying efficient routing paths thatmight not be available for transactions processed in a more traditionalfashion. Routing paths support optimization of transaction value andcost. The routing may be determined via pre-established parametersrelated to such aspects as the identities of the participant parties,risk levels, choice of merchant and/or financial institution, liabilitylevels, and the like.

This capability is used in some embodiments to generate profit. Forinstance, a traditional transaction may include $0.02 in routing costsusing an existing routing network. By providing the host system withaccess not only to that existing routing network, but also to otherexisting routing networks traditionally used in supporting differenttypes of transactions, the host system may identify a routing path thatincurs only $0.01 in routing costs. Access to such a path with itsdecreased costs may be provided by the host system at a cost of $0.015,so that the entity initiating the routing saves $0.005 on thetransaction and the entity operating the host system realizes a profitof $0.005 on the transaction, or realizes a corresponding savings thatmay be schared with contributing parties. The numerical values in thisexample are intended only to be illustrative and the marginal profit isalso only illustrative since other arrangements may be used in differentembodiments.

In addition to using such routing capabilities advantageously in seekingtransaction authorizations, the host system may also use third-partyguarantors to provide transaction authorizations. For example, a thirdparty may offer to consider transaction criteria and provide anauthorization for the transaction, thereby receiving a fee forperforming the authorization and also accepting an associated defaultrisk. In some instances, an entity operating the host system may act asa third-party guarantor and provide a transaction authorization on sucha basis. The information used in performing the authorization mayinvolve statistical or modeling techniques to enable authorizationdecisions to be made on partial information, i.e. without requiring thata particular financial account be accessed to ensure that it has asufficient balance to support the transaction. For instance, atransaction that is to be supported by cellular-telephone minutes mightbe approved by a third party using such techniques on the basis of pasthistory of the customer, not checking the minutes balance in real timebut perhaps doing so later in batch mode when multiple balances may bechecked for multiple customers.

FIG. 5C includes an example of additional functions that may beperformed by the host system 100 separate from a specific transaction inthe form of settlement functions. It is generally expected that the hostsystem 100 will process a large number of transactions using the methoddescribed above. Periodically, such as every day or every week, the hostsystem 100 will coordinate settlement functions with the issuers offunding sources, such as the financial institutions 108, as indicated atblock 556. Such settlement functions ensure that funds transfers aremade as required to accommodate the terms of approved transactions. Thehost system 100 may, of course, perform additional administrativefunctions that are not explicitly shown in FIG. 5C, some of which havebeen discussed briefly above. One example of such an additionaladministrative function is a fraud-analysis that is performed ofmultiple transactions to identify potentially fraudulent activity.

FIG. 5D includes an example of replenishment functions that may beperformed with the host system. Such replenishment functionsadvantageously permit balances in some registered financial accounts tobe funded with balances from other registered financial accounts. Toinitiate such replenishment, a customer contacts the host system 100 atblock 560, such as by using one of the interfaces described inconnection with FIG. 1. To permit the host system 100 to authenticatethe customer and thereby provide access to information used in effectingthe replenishment, the customer provides identification at block 562.Similar to obtaining access for other functions, such identification maycomprise information from a presentation instrument registered to thecustomer by the host system 100 or could comprise authentication datasuch as is usually provided during transactions. After authentication ofthe customer by the host system 100 using this identification at block564, the customer may request financial-account information at block566. Such account information may specify any of a number of parametersthat describe the financial account, including the institution thatholds it, the type of financial account that it is, the balance of thefinancial account, the type of value held by the financial account, andthe like.

After reviewing the financial accounts, the customer may specify areplenishment request at block 568. Such a request defines one or morefinancial accounts to serve as a source for the replenishment value, oneor more financial accounts in which value is to be replenished, andspecifies a value amount. In many instances, the type of value in boththe source and target financial accounts is the same, but in someinstances they may differ, such as where a financial account holdingcellular-telephone minutes is to be used in replenishing a financialaccount holding U.S. dollars. In such instances, specifying the valueamount is usually performed in terms of the source or target value type,although a third value type may be used in making such a specificationin some instances. For example, a replenishment request might ask that$50 worth of frequent-flyer miles from one financial account be used toreplenish a financial account of cellular-telephone minutes.

Because of such possibilities, the host system 100 checks at block 570whether a conversion of value needs to be made as part of thereplenishment function and, if so, performs such a conversion at block574. The replenishment is then effected by the host system 100 at block572. The replenishment is effected by a transfer of value similar tothat used when supporting a transaction except that the financialaccount(s) where the value originates and the financial account(s) towhich it is sent are owned by the same party.

It is also noted that while each of FIGS. 4A-5D provides an exemplaryset of functions and an exemplary order for those functions, variationsare also intended to be within the scope of the invention. Inparticular, there is no requirement that the functions represented bythe blocks be performed in the order indicated; in alternativeembodiments, various of the functions might be performed in a differentorder. Also, there is no requirement that every indicated function beperformed; in some cases only a subset of the functions might beperformed and in other instances additional functions may also beperformed.

Thus, having described several embodiments, it will be recognized bythose of skill in the art that various modifications, alternativeconstructions, and equivalents may be used without departing from thespirit of the invention. Accordingly, the above description should notbe taken as limiting the scope of the invention, which is defined in thefollowing claims.

1. (canceled)
 2. A method for a customer to conduct a purchasetransaction at a point-of-sale (POS) device, the method comprising:receiving, by a computer system, transaction information and anidentification of a payment instrument of a customer from a POS deviceof a merchant, wherein the transaction information corresponds to thepurchase transaction; guaranteeing the purchase transaction at leastpartially based on a statistical or modeling technique used withoutfirst accessing a payment account associated with the payment instrumentto determine that a sufficient balance is present to support thepurchase transaction; routing, by the computer system, the purchasetransaction, wherein payment of the purchase transaction is guaranteedby an entity operating the computer system; and transmitting, by thecomputer system, a transaction authorization that indicates payment ofthe transaction is guaranteed by an entity operating the computersystem.
 3. The method for a customer to conduct a purchase transactionat a point-of-sale (POS) device of claim 2, wherein: the transactioninformation further comprises authentication information; and the methodfurther includes authenticating, by the computer system, the customerusing the authentication information.
 4. The method for a customer toconduct a purchase transaction at a point-of-sale (POS) device of claim3, wherein: the authentication information comprises a copy of asignature of the customer; and authenticating the customer using theauthentication information comprises comparing the copy of the signaturewith a file copy of the signature to verify an identity of the customer.5. The method for a customer to conduct a purchase transaction at apoint-of-sale (POS) device of claim 2, wherein: the payment instrumentcomprises a negotiable instrument.
 6. The method for a customer toconduct a purchase transaction at a point-of-sale (POS) device of claim2, wherein: the payment instrument comprises a check.
 7. The method fora customer to conduct a purchase transaction at a point-of-sale (POS)device of claim 2, further comprising: receiving, by a computer system,enrollment information to register the payment account, wherein theenrollment information comprises authentication information, theauthentication information comprising: a personal identification number(PIN) selected by the customer; and a telephone number of the customer.8. The method for a customer to conduct a purchase transaction at apoint-of-sale (POS) device of claim 2, further comprising: receiving anencryption certificate from the POS device; and authenticating, by thecomputer system, the customer based at least in part on the encryptioncertificate.
 9. A computer program product residing on a non-transitoryprocessor-readable medium for a customer to conduct a purchasetransaction at a point-of-sale (POS) device, the computer programproduct comprising processor-readable instructions configured to cause aprocessor to: receive transaction information and an identification of apayment instrument of a customer from a POS device of a merchant,wherein the transaction information corresponds to the purchasetransaction; guarantee the purchase transaction at least partially basedon a statistical or modeling technique used without first accessing apayment account associated with the payment instrument to determine thata sufficient balance is present to support the purchase transaction;route the purchase transaction, wherein payment of the purchasetransaction is guaranteed by an entity operating the computer programproduct; and transmit a transaction authorization that indicates paymentof the transaction is guaranteed by an entity operating the computerprogram product.
 10. The computer product of claim 9, wherein theinstructions further cause the processor to: detect patterns of behaviorthat are known to indicate an increased likelihood of fraud.
 11. Thecomputer product of claim 9, wherein: the transaction informationfurther comprises authentication information, the authenticationinformation comprising one or both of a PIN or a copy of a signature ofthe customer; and instructions further cause the processor toauthenticate the customer using the authentication information.
 12. Thecomputer product of claim 11, wherein: authenticating the customer usingthe authentication information comprises comparing the copy of thesignature with a file copy of the signature to verify an identity of thecustomer.
 13. The computer product of claim 9, wherein the instructionsfurther cause the processor to: receive an encryption certificate fromthe POS device; and authenticate the customer based at least in part onthe encryption certificate.
 14. The computer product of claim 9, whereinthe instructions further cause the processor to: receive enrollmentinformation to register the payment account.
 15. The computer product ofclaim 9, wherein: the payment instrument comprises a check.
 16. A hostcomputing system, comprising: a communications interface; a processor;and a memory device having instructions stored thereon that, whenexecuted, cause the processor to: receive, using the communicationsinterface, transaction information and an identification of a paymentinstrument of a customer from a POS device of a merchant, wherein thetransaction information corresponds to a purchase transaction; guaranteethe purchase transaction at least partially based on a statistical ormodeling technique used without first accessing a payment accountassociated with the payment instrument to determine that a sufficientbalance is present to support the purchase transaction; route, using thecommunications interface, the purchase transaction, wherein payment ofthe purchase transaction is guaranteed by an entity operating thecomputer system; and transmit, using the communications interface, atransaction authorization that indicates payment of the transaction isguaranteed by an entity operating the computer system.
 17. The hostcomputing system of claim 16, wherein: the payment instrument comprisesa check.
 18. The host computing system of claim 16, wherein theinstructions further cause the processor to: receive enrollmentinformation to register the payment account, wherein the enrollmentinformation comprises authentication information that is usable toverify an identity of the customer.
 19. The host computing system ofclaim 18, wherein: the authentication information comprises one or moreof a copy of a signature of the customer, a personal identificationnumber (PIN) selected by the customer, or a telephone number of thecustomer.
 20. The host computing system of claim 16, wherein: thetransaction information further comprises a copy of a signature of thecustomer; and the instructions further cause the processor toauthenticate the customer by comparing the copy of the signature with afile copy of the signature to verify an identity of the customer. 21.The host computing system of claim 16, wherein: receive an encryptioncertificate from the POS device; and authenticate the customer based atleast in part on the encryption certificate.